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ABSTRACT 



A vacuum network controller includes a host interface for 
interfacing with a host controller, a component interface for 
interfacing with vacuum system components, a computer- 
readable medium storing software code, and a processor in 
communication with each of the preceding elements. The 
software code generates commands to control the vacuum 
system components, translates those commands into mul- 
tiple communication protocols, and communicates the trans- 
lated commands to the component interface. In a method 
embedded in a set of computer-translatable instructions, an 
instruction is received from a host controller. That instruc- 
tion is processed to generate a command for controlling a 
vacuum system component. A software driver is selected 
from a library of drivers for communication protocols, and 
the selected software driver is used to translate the command 
into the respective protocol. Finally, the translated command 
is communicated to a component interface to control the 
operation of the vacuum system component. 

45 Claims, 5 Drawing Sheets 
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VACUUM NETWORK CONTROLLER In another preferred embodiment, the software code iSi ^ 

BACKGROUND OF THE INVENTION ^'''^ '° translate communications between the vacuum net-\ \ 

work controller and both the host controller and a vacuum \ 

Acryogenic vacuum system typically includes at least one ^ component to and from more than one of the 

cryogenic vacuum pump (cryopump) and at least one com- , fon^^j communication protocols: BitBus. EtherNet. 

pressor for supplymg compressed helium to the cryopump. t/^d/id dc t5-> no ^oc r; • kf . n en j r- u I 

The system also often includes other components^such as ^^'^l RS-485 DeviceNet, ProfiBus and Ech- 

roughing pumps, walerpumps, turbopumps; chdlers, valves embodiment the software code fiirther enables / y 

and gauges. Together, these components operate to provide processor to process data transmitted from components ( ' 

cryogenic cooling to a broader system, such as a cluster tool ^ analog form. 

for semiconductor processing. In yet another preferred embodiment, the software code is 
A cluster tool includes a tool host controller providing able to monitor and control the vacuum system by process- 
top-level control over all systems within the cluster tool. The ing operating data from the vacuum system components, 
tool includes a series of processing chambers for performing In still another preferred embodiment, the software code 
various semiconductor-fabrication processes such as wafer is able to generate commands for controlling components 
etching, chemical or plasma vapor deposition, oxidation, 15 other than a cryopump. In various embodiments, the soft- 
sintering, and annealing. These processes often are per- ware code can generate commands to control components, 
formed in separate chambers, each of which includes a s^ch as a roughing pump, a compressor, a turbopump and a 
cryopump of the cryogenic vacuum system. g^te valve. Further, the software code is responsive to data 
In addition to the cryopumps, a conventional vacuum received from various vacuum system components, such as 
system typically mcludes a network interface terminal which 20 sensors as well as those listed, above. 

communicates in the RS-232 protocol with the tool host * ^*..r^ 1, f *u- • *• • 1 

, , , • . . t_ ,^ • t A vacuum network of this invention includes a vacuum 

controller and also commumcates in the BitBus protocol to t . ^ * n 1 u j u 1 i.- 1 

, , - .1. ^ . network controller, as descnbed above, and multiple 

the network of cryopumps within the system. Other vacuum components in communication with the 

system components, such as a roughing pump compre^r, The plurality of components includes 

and gate valve, are typically coupled with the tool host 25 „ „ „,u^,u « J. ^ pf „ * • *• 

, , .-^^ 1 V 11 components which respond to different communication pro- 
controller to allow the tool host controller to issue com- tocols 

mands for controlling the operation of these components. , 

In a preferred embodiment of this network, a host con- 

SUMMARY OF THE INVENTION troller is in communication with the host interface of the 
The network interface terminal of existing systems of the 30 vacuum network controller. In other preferred embodiments, 
type described, above, provides responsive and custom- a cryopump, roughing pump, compressor, or turbopump is in 
tailored control over cryopumps in a cryogenic vacuum communication with the component interface of the vacuum 
system. Nevertheless, the nature of existing systems is network controller. In yet another preferred embodiment, the 
limited in the following ways. First, the network interface network includes a remote central controller in communi- 
terminal can only accommodate components that commu- 35 cation with the vacuum network controller and also with a 
nicate in the protocol in which the terminal is programmed plurality of other vacuum network controllers for monitoring 
to communicate. The network interface terminal's commu- and controlling those networks. A final preferred embodi- 
nication with cryopumps is typically limited to BitBus, "^^^it of the network includes multiple cryopumps in com- 
while its communication with the host controller is typically munication with the component interface, with different 
limited to RS-232. Nevertheless, a variety of other protocols 40 cryopumps being responsive to different command codes, 
exist, and many components are designed to communicate in A method of this invention is embedded in a set of 
one of these other protocols. A similar problem exists in computer-translatable instructions performed in a controller 
terms of communicating with the host controller. Further, the for controlling a vacuum network. The method includes the 
control capability of the network interface terminal is lim- steps of receiving an instruction from a host controller, 
ited because its capacity for control is confined primarily to 45 processing the instruction to generate a command for con- 
cryopumps in the system. Further still, the limited capabili- trolling a vacuum system component, translating the com- 
ties of the network interface terminal places a considerable mand into one of the plurality of communication protocols 
burden on the host controller, in terms of monitoring and with the selected component software driver, and commu- 
controUing vacuum system components. This burden is nicating the translated command to a component interface to 
evidenced in the bundle of cables that typically link various 50 control the operation of the vacuum system component, 
vacuum system components with the host controller. One version of this method further includes the step of 
A vacuum network controller of this invention includes a selecting from a library of component software drivers for 
processor, a computer-readable medium storing computer- different communication protocols to find a driver to trans- 
executable software code, a host interface for communicat- late the command for controlling the vacuum system com- 
ing with a host controller, and a component interface for 55 ponent. A second version of the method includes the step of 
communicating with components. Both interfaces commu- translating the instruction received from the host controller 
nicate with the processor, as does the computer- readable into an internal protocol for processing within the vacuum 
medium. The software code stored on the computer-readable network controller. 

medium has the capability to perform the following opera- In a preferred embodiment of the method, the operation of 

tions: generating commands to control vacuum system com- eo a cryopump is controlled. In another preferred embodiment, 

ponents interfaced with the component interface; translating a second command is generated, and a second software 

those commands into a plurality of communication proto- driver is selected to translate the second command into a 

cols; and communicating the translated commands to the second protocol to control the operation of a second com- 

component interface. ponent using a communication protocol distinct from that of 

In a preferred embodiment, the software code is able to 65 the first component. In various versions of this preferred 

translate instructions from a host controller and use these embodiment, the second vacuum system component is a 

translated instructions as a basis for generating commands. roughing pump, a compressor, a gate valve, or a second 
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cryopump. Another preferred embodiment of this method host can have a single point of access to the vacuum system 

includes the steps of receiving data from two vacuum system rather than separate points of access for many different 

components, such as those just listed, and using that data to components. The increased functionality of the vacuum 

diagnose a problem in the vacuum network. A vacuum network controller reduces processing congestion at a tool 
system component can then be controUed to remedy the 5 ^^^^ ^^^^^^^^^ ^^^^^ ^ simultaneous transmissions from 

problem. , . , . . . . , . 

-J... multiple vacuum components m conjunction with the pro- 

In yet another preferred embodiment of this method, a . , , • . j *i. r *i- . i 

, r . cessing tasks associated with the operation of other tool 

replacement for an old vacuum system component is auto- * t^, * j- » l *• r 

n jLL-.j- ^ir . ^. components. The greater distnbution of processing respon- 

configured by building a file of operation parameters for the , . . , ^f. . rr.u 

,j , r , . . . 10 sib ihties also improves the robustness of the system. If there 

old component and loading those parameters into a new . • r -i ♦ i i • -um- 

^ . . , . , J IS a processing failure at one level, processing responsibih- 

component installed to replace the old component. Still . , ^ . , \. i , t- n 

- , .j- .fu- L ti^s can often be transferred to another level. Fmally, the 

another preferred embodunent of this method includes the , , r^ , i . . u ^ 

J . \ ^ , , . enhancement of lower-level processing increases the speed 

additional steps of identifyma vacuum system components u - u • c ^ r ^ 

. ^ ^ , ? . M . . , . wuh which processmg funcUons can be performed, 
m the vacuum network, and building routmg tables for 15 

distributing data from the vacuum system components and BRIEF DESCRIPTION OF THE DRAWINGS 

for distributing commands for operating the vacuum net- The foregoing and other objects, features and advantages 

work based on the identity of vacuum system components, of the invention will be apparent from the following more 

The apparatus and methods of this invention offer the particular description of preferred embodiments of the 

following advantages. invention, as illustrated in the accompanying drawings in 

First, conU-ol over the vacuum network is essentially which like reference characters refer to the same parts 

protocol independent, significantly reducing the diflSculty of throughout the different views. The drawings are not nec- 

coordinating use of components that operate under different essarily to scale, emphasis instead being placed upon illus- 
communication protocols. Protocol independence affords 25 trating the principles of the invention, 

the engineer of the system with greater latitude in selecting FIG. 1 is a schematic diagram of a cryogenic vacuum 

components because the protocol by which a component network. 

communicates need not be a hmiting factor, thus saving piG. 2 is a schematic diagram of a cryogenic vacuum 

costs and increasing functionality within the system, network wherein a waterpump has been added. 

Further, the increased capabilities of the vacuum network pic. 3 is a schematic diagram of a cryogenic vacuum 

controller allow a variety of components to be connected network wherein a turbopump has been added. 

thereto and integrated into the system without having to 4 ^ ^ schematic diagram of the hardware in a 

change the software of a tool host, which is generaUy very ^^^^^^ ^^^^^^^ controUer. 

^ , , ' , . FIG. 5 is a schematic diagram of the operational structure 

Second, because the vacuum network controller is more ^ ^^^^^^ ^^^^^^^ controller, 

broadly integrated into the vaaium network, in comparison ^ ,^ ^ ^^^^^ .^^ 

to a network interface terminal of the prior art, the vacuum . , , 1 » n • u j r 

, ^ , ' ... performed by a vacuum network controller in a method of 

network controller can monitor and control the network with ■ • 

, ... , . , 40 this invention, 

greater responsiveness and with enhanced abmty to detect 

and diagnose problems. For example, by monitoring several DETAILED DESCRIPTION OF THE 

components, such as pumps, gauges and valves, the data INVENTION 

from each can be used to better triangulate the source of The features and other details of the method of the 
problems. Further, the broader integration of the vacuum 45 invention will now be more particularly described with 

network controller allows system-wide problems to be reference to the accompanying drawings and pointed out in 

addressed at the system (including the vacuum chamber and the claims. Numbers that appear in more than one figure 

subfabrication subsystem) level rather than at the component represent the same item. It will be understood that the 

(e.g., cryopump) level, and the interactions and effects of particular embodiments of the invention are shown by way 

interactions between components can be better monitored of illustration and not as limitations of the invention. The 

and responded to. Further still, the integrated operation of principal features of this invention can be employed in 

the vacuum network controller enables improved control various embodiments without departing from the scope of 

coordination over resources such as rough valve mapping the invention. 

and management over the supply and distribution of com- 55 A cryogenic vacuum network is illustrated in FIG. 1. The 

pressed helium in comparison to the conventional practice of vacuum network includes a vacuum network controller 12 

merely "passing the token," wherein resource allocation is and a host link 14 to a host controller, which in this 

sequentially distributed in accordance with a fixed schedule. embodiment is a tool host controller 16. The tool host 

lliird, the more active role in system management controller 16 controls the operation of a cluster tool for 

assumed by the vacuum network controller reduces the semiconductor processing. ITie tool host controller 16 can 

processing responsibilities of the host controller. The control the operation of each of the processes (e.g., etching, 

vacuum network controller of this invention increases the chemical vapor deposition, and annealing) performed within 

functionality of control at a lower level of the system. I.e., the cluster tool as well as the operation of the vacuum 
many control functions can be carried out by the vacuum 55 network. 

network controller rather than having to rely on the host The vacuum network further includes a component link 

controller to perform these functions. Accordingly, the tool 18 connected to vacuum system components, such as one or 
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more cryopumps 20, roughing pumps 22, waterpumps 24 controller 12. Alternatively, the remote central controller can 

and turbopumps 26. The vacuum network also includes the be connected by other means such as LAN or internet. The 

gate valves 28 regulating the opening and closing of the remote central controller 40 is similarly linked to many other 

passages between the cryopumps 20 and the respective vacuum networks so that it can remotely monitor and, if 
chambers that the cryopumps 20 are employed to evacuate. 5 necessary, control the operation of each. 
The status of each of these components can be monitored A schematic diagram of the hardware structure of a 

and controlled by the vacuum network controller 12. Further vacuum network controller 12 is provided in FIG, 4, A data 

still, the vacuum network controller 12, in one embodiment, bus 79 and address bus 80 link each of the illustrated 

includes a variety of sensors, including a residual gas elements and support data communication therebetween, 
analyzer, an ion gauge, and a capacitance manometer. Each The vacuum network controller further includes a series 

component that is added to the network provides additional of interfaces connected to the buses 79, 80. First, a host 

data which enhances the ability of the vacuum network interface 61 provides a connection for coupling the vacuum 

controller to perform predictive diagnostics on the system. network controller 12 with a tool host controller 16. Second, 
In another embodiment, communication to and from each of 15 a component interface includes both a Bitbus interface 68 

the components is daisy chained into a processor within one and one or more other interfaces 70 which provide a 

of the cryopumps 20. Accordingly, this embodiment supplies connection to vacuum system components. Th e various 

an additional, lower level of processing capabihty. interfaces for communicating with vacu um system comp o- 

Bccause all vacuum system components are connected to nents are collectively reterreo to as the "component inter- 

the vacuum network controller 12, components can be added f^s^ Tliird, a servic e int crface Sg provides a connection 

or subtracted from the vacuum network without needing to whereby a technicjAn _can Jm era c^^ 

notify or reprogram the tool host controller 16. For example, l ocally or rem otely. The physical aspects of each^interface 

FIG. 2 illustrates a vacuum network wherein a network can vary according to the requirements of the communica- 
interface terminal is replaced with a vacuum network con- 25 tion protocol(s) that they are designed to accomodate, 

troller 12, and a turbopump 26 and turbo controller 30 are Fourth, a user interface connects to a terminal or monitor 

installed in the vacuum network. In this embodiment, com- accessible to the user of the network, 
munication with tte turbopump 26 is routed through the A processor 74 drives the operations of the vacuum 

newly-installed vacuum network controller 12. Communi- np%f^rif rnntmiipr p iash storag e 75 provides lony-terrri Ul 
cation with the existing waterpump 24 is also routed through ^ memory storage and supplies the processor 74 with modules 

the vacuum network controller 12. As is more fully dis- tor pertorminp an initialization process 52 (Ff G , ^ T|4pmr.r^7 

cussed below, the vacuum network controller 12 is pro- 76 supplies the processor 74 with short-term memnrv cap a- 

gra mmed to survey the identity of components attached to it ^bihty. Further, the processor 74 is coupled to an expansion 
"ana to automatically confi gure those components for opera: 35 port 78, which allows parallel layers of the structure illus- 

r^Vn ^^'^ ^^^^ xiflf iiirrv i netwonc . Accordingly, responsibility trated in FIG. 4 to be coupled together for increased 

for managing the newly-installed turbopump 26 can be processing, memory storage, and communication capabili- 

assumed entirely by the vacuum network controller 12 so ties. 

that the host controller need not be reprogrammed or bur- xhe operational structure of the vacuum network control- 

dened with even the knowledge of the presence of tur- ler 12 is illustrated in FIG. 5. At the center of the cnmmn- 

bopump 26 in the system. nication structure of the vacuum network controller 12 is a 

FIG. 3 illustrates a similar situation, wherein a network message router 48 for directing communications within the 

interface terminal is replaced with a vacuum network con- vacuum network controlle r 12. Controller operation com- 
troller 12, and a waterpump 24 is installed in the vacuum 45 mences with a power-up Hiap^^ f^^ttirjt , pjncRs.*; which 

network. In this embodiment, communication with the tur- identifies componepts coupleH" with the'^acuum rietwork 

bopump 26, which was previously routed through a direct controller 12 and tests the functionality of network hardware 

link 31 between the host controller 16 and a turbo controller and software. During this testing, the vacuum network 

30, is rerouted through the newly-installed vacuum network controller 12 is not available to govern vacuum network 

controller 12. As in the preceding embodiment, the vacuum operation. The following components are tested: the central 

network controller 12 assumes full responsibiUty for moni- processing unit and its associated memory; power supply 

toring and controlling both the turbopump 26 and the circuitry; measurement circuitry; and input/output 

waterpump 24. interfaces, such as relays, communications, etc. As shown. 

Returning to the vacuum network of FIG. 1, the network 55 the pow er-up diagnostics 50 passes control to an initializa -^ 

also includes a subfabrication (subfab) subsystem connected tion process 52 for initializing the vacuum network control- 

by a subfab link 32. The subfab subsystem includes the l er 12*s hardware/software system based on the make-up of 

machinery needed to support vacuum system components attached components identified during the powcr-up dia^- 

(particularly, the cryopumps 20). In this embodiment, the nostics SO . Modules are drawn from the flash storage 75 

subfab subsystem includes a compressor 34 for supplying (FIG. 4) in doin^ so. The initialization process 52 also 



compressed helium gas to the cryopumps 20, a chiller 36 for produces a collection of routing tables 54 that enable the 

message router 48 to distribute and dynamically link infor- / 
mation within the vacuum network controller 12. ' 



circulating cooling water through the compressor 34, and a 
roughing pump 38 

The vacuum network also includes a remote central ^5 A control process 56 supports the monitoring and con- 
controller 40 connected, by modem 42, to a server 44 which trolling functions of the vacuum network controller 12. The 
is joined through a remote link 46 to the vacuum network service interface 58 provides a technician with service 
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access to operations within the vacuum network controller. 50 are performed upon start-up of the vacuum network 

In a preferred embodiment, the communication port of the controller 12. Initially, the power-up diagnostics process 50 

service interface 58 communicates in RS-232. However, the identifies the components that are in the vacuum network, 

architecture can alternatively support various communica- The diagnostics process 50 then informs the vacuum net- 

tion protocols. An event generator 60 enables user-definable ^ work controller 12 of the communication protocol and 

events to be generated in addition to a standard set of system command codes needed to manage the operation of each 

events. The host interface 61 provides communication to and component. The vacuum network controller 12 then builds 

from the tool host conlroUer 16 (FIG. 1). A global resource ^^^^^^S tables 54 based on its determination of what is 

control process 62 assumes the responsibility of coordinat- :,o connected to the network. The power-up diagnostics 50 

ing and controlling operation of common resources, such as ^^^^^^^^ ^^^^^^^ ^" 

the helium system and the roughing pump 22 (FIG. 1) \ networked component (e.g., a cryopump 20) has been 

r™ , . 1 .1 ^ J / replaced, the new component IS auto-configured by loading 

system. The global resource control process 62 analyzes data ^' • ^ , , t ^ . 

. - ,„ . the configuration parameters of the replaced component mto 

collected from various network components to define, to the * ^i. . u • i t. . ^ . 

, . ic the new component, with the parameters bemg calibrated to 

extent practicable, the most effective and efficient allocation ♦u^ ^ ™ 

the new component. 

of those common resources. The architecture is further ^ .ill • i- j j t 

,.. r Once the network has been initialized and the routing 

designed to accept additional global resources for monitor- ^^^^^^ 54 established, communication can pass to, from, and 

mg and controlhng the vacuum network. ^^^^^^^ ^^^^^ ^^^^^^^ controUer 12. The tool host 

An online/offline diagnostics process 64 performs back- 20 controller 16 will typically maintain a supervisory level of 

ground diagnostics to ensure proper operation of the vacuum control over the operation of the vacuum network and will 

network controller 12 and the vacuum network. Online issue instructions to the network to perform certain functions 

diagnostics are non-intrusive to the operation of the vacuum in response to the vacuum-related needs of the cluster tool, 

network and, therefore, can be performed without disrupting The tool host controller 16 may also request data from the 

operation of the vacuum network. Meanwhile, offline ddag- vacuum network to detennine the status of vacuum opera- 

nostics are provided to isolate problems within the vacuum lions. When issuing instructions, the host controller 16 sends 

network. Offline diagnostics are intrusive to the operation of ^n instruction (e.g., "vacuum on" or "regenerate cryopanel") 

the vacuum network and must therefore be performed with vacuum network controller 12, which receives the 

the vacuum network, or at least part of the vacuum network, 30 instruction at its host interface. 

taken "offline." Typically, the offline diagnostics will pro- A computer-software-based process for processing this 
vide more thorough information regarding operating condi- instruction is illustrated in the form of a flow chart in FIG. 
tions. 6. After receiving 82 the instruction at a host interface 61 
Much of the diagnostic data is forwarded to the user network controUer 12 (FIGS. 1, 4 and 
through the graphical user interface 66, where the user can ^) ^ appropriate software driver from a 
monitor and control the vacuum network controller 12. In ^^^^^y^ '^^'''^ ^"^^^^^^ software drivers for translating 
one embodiment, a screen or terminal is provided specifi- ^^^"^^ ^^-232, RS-485, DeviceNet, EtherNet, TCP/IP, 
cally to serve as an interface for the vacuum network user. ProfiBus and Echelon mto a genenc protocol mteraal to the 
In an alternative embodiment, the vacuum network control- 40 network. Software drivers for other protocols cur- 
ler 12 is provided with a software driver for communicating '^"^^y ^" existence as well as those that are yet to be 
with a screen or terminal, which is used for other purposes, developed are likewise incorporated into the Ubrary as need 
within the vacuum network. develops. In one embodiment, that generic internal protocol 

. , . . • . r • . .1. is built on a Win32 operating system (Microsoft Corp.). The 

A standard MSUS mtBrto ffl fi9pim..n|9i^ffifi With, ,, y^^,; „f ^ ^^^^^^ 

van mm Sy^^^^'^f.ijnXOmpf^PnPtSi.tllM UtlllZC thc Blt Bu S PrOtOCOl. 11 c ^ • T L XT . r 

-PT-rrrr^^ generally of no real significance, however. Next, the soft- 



DeviceNet, 



Eurther, other component interfaces 70 (e.g., >^ w,.w^ .,^., , . , . . 

iTTirSL^o y.Qc^J^ '! ^^-^ 4 ^ ' -.u w^r^ driver translates 86 the host s mstmction into the 

Profi BusrTiS«4855gn aJlo&pcommu nicate with v acuum sys- . , , . 1 ^ 1 . , . ... 

« Ju / I'P^Tl . 1 l ' internal protocol. The translated host instruction is then 

t^.m p^pipnnp.nts tha^ utilize these protocnk. Each mmmn- j 00 u *u /t-f^ a\ 

. ' ' - / . ■ ~ , .- — rrrrt processed 88 by the processor 74 (FIG. 4) to generate 

nicatinp prnt^cnl ha s its own f fnftwflxe driver. W hile some 50 J / / 1 1 

, . J i.-^-"tt~ ' T i_ J specific operating commands (e.g., commands to close the 

protocols can nevertheless share the same interface hard- . f , ^«/r.T^\f . 

/■ u • 1 . \ *u appropriate gate valve 28 (FIG, 1) and warm the appropriate 

ware (i.e., the same physical connector), others requu^e ^ = \ / rr r 

, u j /J / j-ir • cryopump 20) to effect the result sought by the host mstmc- 

separate interface hardware (due to different pin 1 . . , 

n ^- r IX tion based on the vacuum network controller 12 s knowl- 

conngurations, for example). , r 1 . ■ . , , . . 

55 edge of the components that are in the network and their 

Finally, a logger 72 with the ability to store vacuum operational status. Again, an appropriate software driver is 
network information that can be retrieved locally and/or . selected 90 fro m a librarv of drivers for translatin g the 
remotely for analysis is provided. The logger 72 basicaUy "genenc iii r^rnal protocol into a compo ne nt protocol, such as 

keeps a record of all that happens in the vacuum network, (but, again, not limited to) BitBus, btherNet. TCP/IE. 
including events, conditions, and parameter changes. This ^0 RS-232, RS-485, DeviceNet. ProfiBus, or Echelon, and the 

mformation can be stored locally or at a remote site. software driver translates 92 the commands into the protoco l 

Some of these operations have their own processor, others of_the selected driver. The translated commands are then 

share processors. communicated 94 to a component interface 68/70 (FIG. 4), 
The standard operation of an embodiment of a vacuum 55 from where they are delivered to the appropriate vacuum 

network controller 12 of this invention includes the follow- network component(s). The component(s), in turn, respond 

ing processes. First, as noted above, power-up diagnostics (s) to those commands. 
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The communication traffic between the vacuum network 
controller 12 and vacuum system components is typically 
bidirectional. For example, vacuum system components 
typically feed data regarding their operational status and 
measurements that they perform back to the vacuum net- 
work controller 12. The component can send data to the 
vacuum network controller 12 on its own volition or in 
response to a prompt for such data from the vacuum network 
controller 12. Data from the component is received at a 
component interface 68/70 of the vacuum network controller 
12. The vacuum network controller 12 then selects the 
appropriate software driver from a hbrary including drivers 
for translating BitBus, Ethernet, TCP/IP, RS-232, RS-485, 
Device Net, ProfiBus, Echelon and analog signals into the 
generic internal protocol. The translated data is then pro- 
cessed by the processor 74 (FIG. 4) into basic status infor- 
mation to be forwarded to the host controller 16 and/or a 
display or used to generate specific operating commands. 
One example where the vacuum network controller 12 
processes component data to generate operating commands 
includes use of the event generator 60. For example, the 
event generator 60 can be programmed to monitor the 
temperature of a component and, if the temperature of that 
component rises above a given value, to respond by either 
shutting down the component, initiating countermeasures, or 
notifying the system user. The specific nature of the response 
is pre-defined by the system user. 

The vacuum network controller 12 also communicates 
with the network user through the graphical user interface 
66. Further still, the vacuum network controller 12 commu- 
nicates with technicians through the service interface 58, 
which provides programming capabilities to afford manual 
control over the vacuum system and its components. 

Finally, the vacuum network controller 12 communicates 
through a server 44 and by modem 42 with a remote central 
controller 40 located at a separate site from the vacuum 
network. The vacuum network controller 12 sends informa- 
tion regarding network operation to the remote central 
controller 40. Further, the remote central controller 40 can 
send a prompt to the vacuum network controller 12 to 
request this information. The remote central controller 40 is 
likewise Unked to dozens of similar vacuum networks. As a 
result, the remote central controller 40 develops an extensive 
database of observations of network operation, and it draws 
upon this database to analyze network problems as they 
develop. Further, the remote central controller 40 monitors 
the success of various responses to particular network prob- 
lems to augment its ability to issue or suggest a response for 
dealing with new problems as they arise. Accordingly, the 
vacuum network controller 12 can call on the remote central 
controller 40 to assist in diagnosing and responding to 
perceived problems in vacuum network operation. 

In addition, the remote central controller 40 periodically 
prompts the vacuum network controller 12 for information 
regarding the performance of vacuum system components. 
As a result, the remote central controller 40 can perform 
predictive diagnostics to detect problems such as aging of a 
component. Cryopumps 20, for example, typically show 
signs of aging before they fail after exhausting their useful 
hves. By analyzing operating data, such as that relating to 
temperatures, pressures, displacer speeds, and/or motor 
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torque, the remote central controller 40 can recognize the 
aging of a cryopump 20. When it recognizes aging, the 
remote central controller 40 sends instructions back to the 
vacuum network controller 12 to take remedial action (e.g, 
to increase the rate of displacer reciprocation within the aged 
cryopump 20) and sends a message to the service technician 
to replace that cryopump 20 during the next scheduled 
maintenance outing. The capacity to promptly detect and 
predict component problems greatly advances the goal of 
being able to perform all necessary maintenance during 
scheduled maintenance trips. Of course, if the condition of 
a component is recognized as being imminently dire, the 
remote central controller 40 can direct maintenance to be 
15 performed before the component ceases to function at an 
acceptable level of effectiveness. Accordingly, the risk of 
network downtime due to component failure can be signifi- 
cantly reduced. 

While this invention has been particularly shown and 
described with references to preferred embodiments thereof, 
it will be understood by those skilled in the art that various 
changes in form and details may be made therein without 
departing from the spirit and scope of the invention as 
defined by the appended claims. 
What is claimed is: 

1. A vacuum network controller comprising: 
a processor; 

a host interface in communication with the processor for 

interfacing with a host controller; 
a component interface in communication with the 
processor, comprising a plurality of interfaces for inter- 
facing with respective vacuum system components, 
including vacuum system components other than 
vacuum pumps, using distinct communication proto- 
cols; and 

a computer-readable medium in communication with the 
processor, the computer-readable medium storing 
computer-executable software code for: 
generating commands to control vacuum system com- 
ponents; 

selecting from a library of component software drivers 

for a plurality of communication protocols; 
translating the commands into the control vacuum 
system components' respective communication pro- 
tocols with the selected component software driver; 
and 

communicating the translated commands to the respec- 
tive component interfaces. 

2. The vacuum network controller of claim 1, the software 
code being able to translate the software-generated com- 
mands into more than one communication protocol selected 
from the group consisting of BitBus, EtherNet, TCP/IP, 
RS-232, RS-485, DeviceNet, ProfiBus, and Echelon. 

3. The vacuum network controller of claim 1, the software 
code being able to process data received from vacuum 
system components. 

4. 'Ilie vacuum network controller of claim 3, the software 
code being able to process data received from a sensor 
selected from the group consisting of a residual gas analyzer, 
an ion gauge, and a capacitance manometer. 

5. The vacuum network controller of claim 3, the software 
code being able to process data received from a tool selected 
from the group consisting of a roughing pump, a 
compressor, a lurbopump, and a gate valve. 
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6. The vacuum network controller of claim 3, wherein the 17. The vacuum network of claim 16, further comprising 
software code enables the processor to process data trans- a host controller in communication with the host interface, 
milled from vacuum system components to the component 18. The vacuum network of claim 16, further comprising 
interface in a protocol selected from the group consisting of a cryopump in communication with the component inter- 
BitBus, EthcrNet, TCP/IP, RS-232, RS.485, DeviceNet, 5 face. 

ProfiBus, Echelon, and analog. 19. The vacuum network of claim 16, further comprising 

7. The vacuum network controller of claim 1, the software a roughing pump in communication with the component 
code further being able to translate a plurality of commu- interface. 

nication protocols to and from the host interface. 20. The vacuum network of claim 16, further comprising 

8. The vacuum network controller of claim 7, the software a compressor in communication with the component inter- 
code being able to translate more than one communication face. 

protocol selected from the group consisting of BitBus, 21. The vacuum network of claim 16, further comprising 

EtherNet, TCP/IP, RS-232, RS-485, DeviceNet, ProfiBus, a turbopump in communication with the component inter- 

and Echelon to and from the host interface. ^5 face. 

9. The vacuum network controller of claim 7, the software 22. The vacuum network of claim 16, further comprising 
code further being able to generate a command derived from ^ S^^^ ^^^^^ communication with the component inter- 
an instruction received from the host controller. 

10. The vacuum network controller of claim 1, the ^3. The vacuum network of claim 16, further comprising 
computer^xecutable software code further for: 20 a remote central controller in communication with the 

. , , vacuum network controller, 

processmg component data; and '^a ^ * 1 r 1 • 11 i. • *i_ 

^ • , r , 24. The vacuum network of claim 23, wherem the remote 

generating a command for controlling a component other . 1 * n • • • -.i. 1 1* r 

^ & r central controller is in communication with a plurality of 

than a cryopump. . 1 * n / 

J I- r f 1 in . • othcr vacuum nctwork controllcrs. 

11. The vacuum network controller of claun 10, wherein ^ . r , • ^ , 

. , ... 25 25. The vacuum network of claim 16, further comprising 

the component other than a cryopump is a roughing pump. 1 1* r * * -.l 

^ , ^ , . f r a plurahty of cryopumps m communication with the com- 

12. The vacuum network controller of claim 10, wherein . • . _r ^. . • • . j- . 

' poneni mlerface, the cryopumps bemg responsive to distmct 

the component other than a cryopump is a compressor. command codes 

13. The vacuum network controller of claim 10, wherein 26. A method embedded in a set of computer-translatable 
the component other than a cryopump is a gate valve. 30 i^stmctions performed in a controller for controlling a 

14. The vacuum network controller of claim 10, wherein ^^cuum network, the method comprising the steps of: 
the component other than a cryopump is a turbopump, ^^^^-^^g ^„ instruction from a host controller; 

15. The vacuum network controller of claim 1, the processing the instruction to generate a command for 
computer-readable medium further storing computer- controlling a vacuum system component; 
executable code for: ^.^ selecting from a library of component software drivers 

coordinating and controlling operation of common for a plurality of communication protocols; 

resources of the vacuum system. translating the command into one of the plurality of 

16. A vacuum network, comprising: communication protocols with the selected component 
a vacuum network controller, including: 40 software driver for the vacuum system component; and 

a processor; e) communicating the translated command to one of a 

a host interface in communication with the processor plurahty of component interfaces to control the opera- 

for interfacing with a host controller; tion of the vacuum system component, 

a component interface in communication with the 27, The method of claim 26, wherein the selected software 

processor, comprising a plurality of interfaces for 45 driver is from the group consisting of BitBus, Ethernet, 

interfacing with respective vacuum system ^CP/IP, RS-232, RS-485, DeviceNet, ProfiBus, and Ech- 

components, including vacuum system components ^^^^ 

other than vacuum pumps, using distinct communi- .t_ j r 1 ■ • • .1. . 

cation protocols- 28, The method of claim 26, further compnsing the steps 

a computer- readable medium in communication with 50 
the processor, the computer-readable medium stor- selecting from a library of host-controller software driv- 
ing computer-executable software code for: ^rs; and 

generating commands to control vacuum system translating the instruction into another protocol with the 

components; selected host-controller software driver, 

selecting from a library of component software driv- 55 29. The method of claim 26, wherein the operation of a 

ers for a plurality of communication protocols; cryopump is controlled, 

translating the commands into the control vacuum 30. The method of claim 29, wherein a second command 

system components' respective communication for controlling a vacuum system component is generated and 

protocols with the selected component software ^^^^^ (^)^ ^^e repeated to control the operation of 

driver, and 60 ^ second vacuum system component, 

communicating the translated commands to the ,^ . ^ 1 . ^« t. • l 

^1- Th^ method of claim 30, wherem the second com- 

respective component interfaces; and ^ . , , . . . . 
a plurality of vacuum system components in commu- "^^^^ ^ translated into a communication protocol distmct 
nication with the component interface, different from the communication protocol into which the first corn- 
members of the plurality of vacuum system compo- 65 ^ translated. 

nents responding to distinct communication proto- 32. The method of claim 31, wherein the second vacuum 

cols. system component is a roughing pump. 
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33. The method of claim 31, wherein the second vacuum 
system component is a compressor. 

34. The method of claim 31, wherein the second vacuum 
system component is a gate valve. 

35. The method of claim 31, wherein the second vacuum 
system component is a second cryopump. 

36. The method of claim 31, further comprising the steps 
of: 

receiving data from the two vacuum system components; 
and 

using that data to diagnose a problem in the vacuum 
network. 

37. The method of claim 36, further comprising the step 
of controlling the operation of at least one of the vacuum 
system components to remedy the diagnosed problem. 

38. The method of claim 31, further comprising the step 
of auto-configuring a replacement for an old vacuum system 
component by building a file of operation parameters for the 
old vacuum system component and loading those parameters 
into a new vacuum system component installed to replace 
the old vacuum system component. 

39. The method of claim 31, further comprising the steps 
of: 

identifying vacuum system components in the vacuum 
network; and 

building routing tables for distributing data from vacuum 
system components and for distributing commands for 
operating the vacuum network based on the identity of 
vacuum system components. 

40. The method of claim 26, further comprising the step 
of using a remote central controller to monitor the vacuum 
network as well as a plurality of other vacuum networks. 

41. The method of claim 40, further comprising the step 
of using the remote central controller to control the vacuum 
networks. 

42. The method of claim 41, wherein the remote central 
controller logs data received while monitoring the vacuum 
networks and compares additional data received while moni- 
toring a member of the vacuum networks with the logged 
data to diagnose and remedy a problem in the member. 
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43. A method embedded in a set of computer-translatable 
instructions performed in a controller for controlling a 
vacuum network, the method comprising the steps of: 

receiving an instruction from a host controller; 

translating the instruction into an internal protocol; 

processing the translated instruction to generate a com- 
mand for controlling a vacuum system component; 

selecting from a library of component software drivers for 
a plurality of communication protocols; 

translating the command into a component protocol with 
the selected component software driver for the vacuum 
system component; and 

communicating the translated command to one of a plu- 
rality of component interfaces to control the operation 
of the vacuum system component. 

44. The method of claim 43, wherein the step of trans- 
lating the command into a communication protocol includes 
the steps of: 

selecting from a library of component software drivers for 
a plurality of communication protocols; and 

translating the command into one of the plurality of 
communication protocols with the selected software 
driver. 

45. A vacuum network controller comprising: 

a host interface for communicating with a tool host; 

a component interface comprising a plurality of interfaces 
for communicating with components of a vacuum 
network, including vacuum system components other 
than vacuum pumps; 

a processor programmed to control the components of the 
vacuum network; and a library of component software 
drivers for a plurality of communication protocols 

means for translating commands from the processor into 
any of a plurality of communication protocols with a 
selected component software driver for communicating 
with the respective components of the vacuum net- 
work. 
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